Delegation is the process of an identified entity, called delegator, giving a mandate or a delegation assertion to another identified entity, called delegatee. The delegatee receives the privilege to act on behalf of the delegator at a service provider, who provides services to a requester.
In this specification, the following terminology is used:                a privilege is a right to access specific resources or to perform certain tasks. A user may have a number of such privileges.        a delegation is the act of temporarily or permanently transferring privileges from one entity to another.        a delegator is the entity that transfers, i.e. delegates all or a subset of its privileges to a Delegatee.        a delegatee is the entity that receives all or a subset of the delegator's privileges in order to use them on the delegator's behalf.        a delegation assertion is an assertion of the correctness and authority for a delegation, issued by a Delegation Authority to a delegatee.        a delegation authority or mandate authority is an entity that controls delegation and issues delegation assertions.        
The delegation can be user-to-user, user-to-machine, or machine-to-machine. Existing research on delegation in federated identity management environments focuses on user-to-machine or machine-to-machine delegations. User-to-user delegation has been studied in role-based access control (RBAC) systems, and is typically used with specific service providers. As the Web becomes the ubiquitous computer, and more organizations, government, and businesses operate in and depend on federated identity management environments, user-to-user delegation over the web in such an environment becomes a required functionality. Furthermore, the delegation should also work with different access control models in addition to RBAC.
Access controls are security mechanisms that control how subjects, such as users, applications, and systems access and interact with objects, such as resources, other applications and systems. Access control includes identification, authentication, authorization, and accountability. All organizations and their systems or services must have access control policies and implementations to protect their resources and systems from unauthorized access.
Delegation is a mechanism of transferring access privileges from one subject to another. Such a privilege transfer must be authorized and must not violate organization/system's access control policy to prevent unauthorized access due to the delegation. Therefore, the delegation should be specified as a part of the access control policy. A delegation mechanism must associate and be authorized by the corresponding access control engine. However, recent research on delegation related to the federated identity and machine-to-machine delegations have focused on mechanisms and semantics but failed to establish the link between the delegation and access control.
There are three main types of access control models: discretionary, mandatory, and role-based. The discretionary access control model allows the owner of the resource to specify which subject can access a specific resource. Most operating systems of personal computers, such as Windows, Linux, Mac, have their models based on the discretionary access control. In a mandatory access control model, the system, not the resource owner, makes decisions based on a security label system and a mathematical model, with which data are classified and subjects have clearance labels. In a role-based access control, access decisions are made based on a pre-specified role assigned to the user. This is commonly used in a company or an organization. For example, a manager can access certain resources while an employee cannot. A system can also use a combination of these control models.
The eXtensible Access Control Markup Language (XACML) is a standard-based specification that can be used to specify and communicate access control policies across computer systems, internal or external to an organization. A current version is XACML 2.0. A XACML 3.0 version is working in progress, which includes the concept and process of delegation. However, XACML delegation deals with creation of new policies and tracing back “trusted policies”.
Delegation in Role-Based Access Control (RBAC) can be done for roles or for individual permissions, by granting or transfer privileges. The granting delegation allows the delegated privileges to be available to both the delegator and the delegatee after a successful delegation operation. The transfer delegation transfers the delegated privileges to the delegatee after a successful delegation. Those privileges are no longer available to the delegator. The RBAC system must manage the delegation based on the access control policies. In doing so, it must answer the following two questions:                Is a delegator authorized to delegate a role, privilege, or permission that is available to him?        Can a role, privilege, or permission be delegated to a delegate?        
In the context of delegation service in a federated identity management environment, service providers manage their own access controls and, hence, the permission to delegate. The service provider (SP) must find answers to the above question when a user delegates, when a user invokes a delegation, and when a user's privileges have been changed. This applies to any access control model, not just RBAC.
The system called the Shibboleth System is a SAML 2.0 based, open source software package for web single sign-on (SSO) across or within organization boundaries. The Shibboleth proposes a solution to a proxy authentication problem: how to authenticate a service to which a user may have authenticated to, and who wishes to invoke another service on the user's behalf? For example, a user authenticates to a web portal through an Identity provider (IdP), and then the portal accesses a web service provider as the user. This solution solves the problem of user-to-machine delegation, that is, the user delegates some of his privileges to the web portal to access the service provider on his behalf.
The Shibboleth solution uses two SSO's (Single Sign-On) through the same IdP:                A Web Browser SSO to portal, i.e. user login to portal: an SAML assertion in response to the authentication request from the IdP includes a subject NameID and an additional subject confirmation for the portal that enables the portal to use later to authenticate.        A Portal SSO to the SP: an SAML assertion in response to the authentication request from IdP includes the same subject NameID and subject confirmation as in the first authentication statement and a condition that has a <Delegate> element with the NameID as the portal.        
The delegation assertion is enabled by the first authentication statement and is built into the second authentication statement. Therefore, the delegation assertion is issued and signed by the IdP as represented in FIG. 1.
A delegation framework for Liberty Alliance Project, due to the lack of support in Liberty specifications, is also proposed by Alrodhan and Mitchell. Nevertheless this framework is also designed for user-to-machine delegation. It extends the attribute statement in the SAML assertion to form a delegation assertion. The IdP issues and signs the delegation assertion with the user consent i.e. delegator or privilege owner consent. The Single Sign-On Profiles described in the Liberty ID-FF 1.2 specification provides the base for this delegation framework. This solution described the framework based on three profiles: artifact profile, POST profile, and enable-client profile. The artifact-profile-based requires an additional roundtrip to the IdP and the enable-client-profile-based requires installation of a client to the user's computer.
This framework is similar to Shibboleth's delegation in that the delegatee, through the user agent, gets a delegation assertion from the IdP and then presents it to the target. The differences include using different SSO profiles, different assertions and different ways of encoding the delegation assertion. Shibboleth uses Authentication request and a condition with <Delegate> element whereas the delegation framework of Alrodhan and Mitchell uses a general assertion request, and the attribute statement.
OAuth is an open protocol that enables websites or applications called Consumers, to access protected resources from another website called Service Provider, on behalf of a user, without requiring the user to disclose his login credentials at the service provider to the Consumers. As such, OAuth provides a protocol for user-to-machine delegation, i.e. the user delegates to the Consumer to access some of his resource at the Service Provider. The OAuth protocol has three steps:                The Consumer obtains an unauthorized Request Token from the Service Provider, and redirects the user to the Service Provider.        The user authorizes the Request Token at the Service Provider, which redirects the user back to the Consumer after the authorization.        The Consumer exchanges the authorized Request Token for an Access Token, which is used to access the protected resource at the Service Provider on behalf of the user.        
OAuth is for example used for web applications to access user specific resources on sites with the user's authorization without revealing user's login credentials. OAuth is designed for user-to-machine delegation and is not suitable for user-to-user delegation, as the user, i.e. the delegatee cannot process the protocol messages.
Existing delegations in federated identity frameworks focus on user-to-machine delegation. This allows a service provider A to access user's resources at the service provider B on the user's behalf.
The user-to-machine delegation methods cannot apply to user-to-user delegation because human cannot perform complex cryptographic operations.